OpenEdge Development:<br />Progress Dynamics Advanced Development The attribute control and the object type control

Although this chapter does not go into a detailed discussion of how attributes are created, there are a few basic pieces of information concerning attributes that are important to mention here.

First, every attribute in Progress Dynamics is defined in the Repository database. Attributes can be added and edited using the Attribute Maintenance window on the Progress Dynamics Development window’s Attribute menu. Figure 3–7 shows the definition of the ShowPopup attribute.

There are a few key things to note about this definition that will help you understand how you can modify attribute values.

The Constant Level defines the lowest level of the attribute hierarchy at which a value can be defined for the attribute. This can be:

Class — The attribute is given a value for a class, and that value can never be changed for any object in the class. An example of this is the SupportedLinks attribute, which is defined once for each SmartObject class. If you try to edit an attribute whose Constant Level is Class and you use the dynamic property sheet, you see that the initial value of the attribute is displayed, but you cannot change it.

Master — The attribute is given a value for each master object created in the class, and that value cannot be changed in an instance. If you try to edit an instance attribute whose Constant Level is master and you use the dynamic property sheet, you see that the initial value of the attribute is displayed, but you cannot change it. An example of this is the ObjectName attribute.

Instance — The value can be changed for any instance of the object.

There are five toggle boxes on the window that also help identify where and how you can change the attribute value:

Private — If this toggle box is checked, then the attribute is intended for internal use only. Private attributes are not displayed in the dynamic property sheet and should never be modified by application code. Note that the functions that set and get the attribute value might not themselves actually be declared as PRIVATE for programming reasons, but you should not use them.

Runtime Only — If this toggle box is checked, then the attribute’s value is only set to a meaningful value at run time. It makes no sense to set the value at design time in one of the application design tools. Examples of this include attributes whose values are handles, such as DataSource, and attributes that record the current state of an object at run time, such as objectInitialized. These attributes also do not appear in the property sheet.

Design Only — If this toggle box is checked, then the attribute’s value is only meaningful at design time. These attributes are also not displayed in the property sheet because their values are not used at run time.

Derived Value — If this toggle box is checked, then the attribute value is derived from a calculation that is done by the get and set functions for the attribute and is not actually stored with other attribute values. An example of this is the UpdatableColumns property of an SDO, which is derived from another property called UpdatableColumnsByTable, which itself is used only internally. Because such values are not stored within the SmartObjects or in the Repository, they are also not included in the dynamic property sheet.

System Owned — If this toggle box is checked, then the attribute is essential to the workings of the framework and the basic behavior of applications. These attributes and their initial values should not be changed. Developers need special privileges to change these. Many of these attributes can, however, be set and used at run time.

Thus, you see that many attributes used internally are not displayed in the property sheet for a variety of reasons.

The Lookup Type drop-down list lets you define the way in which the attribute is edited in the Dynamic property sheet and includes the following types:

Free Text — Fill in the attribute value in the property sheet.

List Item Pairs — You select a value from a list of possible values. The items are in pairs because the value stored in the Repository might be a coded value that is not displayed to you.

Dialog — You bring up a custom dialog box to edit the property value. You can also type directly the attribute value. The dialog box is specified in the lookup field value.

Dialog (Read Only) — You bring up a dialog box to edit the property, and you cannot choose any value not presented to you in the dialog box. The Color properties, for example, use a dialog box to choose from a color editor.

Procedure — The property sheet runs a user-defined procedure to edit the attribute value.

There are other limits in defining and using attributes. One important characteristic of an attribute that is not defined in the Attribute Maintenance window is its initial value. This is because attributes are not given values until they are associated with a class. You do this in the Object Type Control window under the Dynamic Development window’s Object menu. This tree view-based window shows all the Object classes in a hierarchy starting with Base, which represents the smart class common to all SmartObjects. Attributes are defined for each class, so an individual object inherits attributes and their initial values from all the classes in its branch of the hierarchy.

Figure 3–8 shows an example of drilling down through the DynView class to locate the FrameMinHeightChars attribute.

The organization of the hierarchy is not entirely accurate for all objects. Some classes such as AppServer are optional parts of other classes, but the TreeView does not represent this option. This is why to locate the DynView class, you expand the Base class, then AppServer, then Visual, then Container (again optional, as a viewer can be a container if it has SmartDataFields such as dynamic lookups and combos in it), then DataVisual, then viewer. This is where you define the default value, if any, for an attribute as used in that class.

It is important to understand that every attribute you use in an object must be defined for the object type at this class level. You cannot simply add an attribute to a single object or a single instance of an object. So when, for example, we described adding an attribute value record for a DataField in the Repository Maintenance tool, this was because attribute values are stored at that level only if they override the default values for the class. So when you add an attribute value record, it must be for an attribute that is defined for one of the classes the object inherits from.

Obviously, all the attributes that are needed to provide all the standard behavior for all the objects in the framework are predefined in the Repository, and in principle, you are likely never to need to use these tools. However, if you define your own objects or create a subclass of an existing object, you can add new attributes that your application needs the objects to have.